"remove normalize call"

Fixes #132765 in theory breaking as we might now treat some previously-ambig hr aliases as rigid when we shouldn't. we may want to explicitly normalize the coercion target in fcx.coerce like the new solver does.

"leak check and lub for closure<->closure coerce-lubs of same defids"

Fixes rust-lang/trait-system-refactor-initiative#233

fn peculiar() -> impl Fn(u8) -> u8 {
    return |x| x + 1
}

the |x| x + 1 expr has a type of Closure(?31t) which we wind up inferring the RPIT to. The CoerceMany ret_coercion for the whole peculiar typeck has an expected type of RPIT (unnormalized). When we type check the return |x| x + 1 expr we go from the never type to Closure(?31t) which then participates in the ret_coercion giving us a coerce-lub(RPIT, Closure(?31t)).

Normalizing RPIT gives us some Closure(?50t) where ?31t and ?50t have been unified with ?31t as the root var. resolve_vars_if_possible doesn't resolve infer vars to their roots so these wind up with different structural identities so the fast path doesn't apply and we fall back to coercing to a fn ptr. cc #147193 which also fixes this

New solver probably just gets more inference variables here because canonicalization + generally different approach to normalization of opaques. Idk :3

This technically allows more code to compile (see the test using TAIT in the commit). I don't think this can be observed on stable though.

In theory this could break existing code that relied on coercing a closure to itself resulting in a fnptr. I don't expect this to really happen in practice and this is an "obvious" bug fix.

leak check fndef<->fndef lubs of the same defids

when coerce-lub'ing a fndef with another fndef we already try to lub it first to avoid coercing to a fnptr unnecessarily. we now leak check after this lub operation.

this avoids us incorrectly considering the fndefs to be equal despite unequal binders and then winding up with borrow checker errors due when coercing to a fnptr would have worked fine. see tests/ui/coercion/leak_check_fndef_lub.rs

this is theoretically a breaking change as there could be dead code that relied on these unsatisfiable region constraints never being checked while also asserting that the output of the lub operation was an fndef. I don't think such code is likely to exist, and even if it does I am comfortable breaking it in favour of making code start working that expects us to coerce to a fnptr for unequal fndefs.

make coerce-lubs order independent

cc #73154 #97206

lub currently equates binders and then just returns the lhs without ever leak checking to ensure the binders are actually equal. this can lead to coerce-lub operations being order dependent, i.e. that a coerce-lub b has differing behaviour to b coerce-lub a.

we also cannot rely on borrow checking actually checking the constraints from equating the binders as lub is a hir-typeck coercion concept that is not relevant once MIR has been built. In the MIR we can simply subtype all the types of match arms with the final type of the match.

it is a forwards compatibility hazard to have coerce-lub be order dependent as it results in an effectively arbitrary inference choice which may or may not actually be correct or compatible with hypothetical future behaviours of lub that actually try to compute a proper lub'd type.

on stable we attempt to make coerce-lubs order independent with two checks:

• Leak check for fndef->fnptr coercions
• Leak check for fnptr->fnptr coercions

on stable we do this regardless of whether the coercion is occuring as part of a coerce-lub or not.

under this PR we have the following checks:

• Leak check for fnptr/fndef->fnptr coercions
• Leak check for closure->fnptr coercions performed as part of a coerce-lub
• Leak check closure/fndef<->closure/fndef coerce-lubs that coerce both sides to fnptrs
• Leak check the fallback lub operation when a coerce-lub does not actually coerce

this is theoretically breaking in two cases:

1. the new leak checks are in dead code where borrowck doesn't emit any errors
2. people have written matches/if-elses/array-exprs that rely on the arbitrary inference choice of the first signature encountered

the second case actually is encountered by a few crates in practice which has been somewhat mitigated by the next change.

improving binder lub

this PR also implements a slight improvement to lub operations on higher ranked types to avoid some regressions: #147565 (comment)

when lubbing two higher ranked types, if one of the binders is empty then we now instantiate the other binder with inference variables and lub the instantiated type with the empty-binder type.

concretely:

• for<'a> fn(&'a ()) lub fn(&'static ())
• only the lhs has bound vars so: fn(&'?a ()) lub fn(&'static ())
• '?a eq 'static passes leak check

whereas the previous behaviour was:

• for<'a> fn(&'a ()) lub fn(&'static ())
• lubbing binders is hard so just equate with invariance: fn(&'!a ()) eq fn(&'static ())
• '!a eq 'static fails leak check

"account for safe target features in fndef<->closure and fndef<->fndef coerce-lubs"

We previously did not take safe target features into account when creating the fn sig for fndefs during fndef<->closure or fndef<->fndef coerce-lubs. We now do allowing coerce-lub to produce a safe fn pointer when fndefs with safe target features are involved. This is consistent with existing (non lub) coercion logic for fndef->fnptr which allows coercing to a safe fn pointer.

r? ghost